home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001219_ccprl@xdm001.c…ranfield.ac.uk _Tue Jun 1 13:08:50 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <ccprl@xdm001.ccc.cranfield.ac.uk>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA24838; Tue, 1 Jun 93 13:08:50 MET DST
  4. Received: from xdm001.ccc.cranfield.ac.uk by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA18525; Tue, 1 Jun 1993 13:30:25 +0200
  6. Received: by xdm001 
  7.     id AA28525; Tue, 1 Jun 93 12:30:18 +0100
  8. Received: by xdm039 (5.57/4.7) id AA12120; Tue, 1 Jun 93 12:30:14 +0100
  9. Message-Id: <9306011130.AA12120@xdm039>
  10. To: www-talk@nxoc01.cern.ch
  11. Cc: ccprl@xdm001.ccc.cranfield.ac.uk
  12. Subject: Line breaks and multibody douments
  13. In-Reply-To: Your message of "Wed, 26 May 93 17:23:17 BST."
  14.              <9305261623.AA05834@xdm001> 
  15. Date: Tue, 01 Jun 93 12:30:12 BST
  16. From: "Peter Lister, Cranfield Computer Centre" <ccprl@xdm001.ccc.cranfield.ac.uk>
  17.  
  18. Well, I knew everyone would disagree with me. Thank you for doing so politely.
  19.  
  20. I'd like to make it clear that I do *NOT* suggest line breaks and / or
  21. page breaks to annoy people, nor because I have a specific interest in
  22. poetry (though I do). Dave Raggett suggested a <poem> tag, and as I saw
  23. no smiley, I assume he was at least semi-serious. IMHO, the idea sucks.
  24. T V Raman made a similar comment about representing the high-level
  25. structure of a poems, but I would claim that that is not the business of HTML.
  26.  
  27. The general philsophy is to be "Keep HTML minimal". I agree, and concur
  28. with the idea of embedding e.g. GIF and TeX. You are right, Dave, that
  29. HTML must not be all things to all men. I would add "or anyone for that
  30. matter". So - let us maintain the high-level representations of our
  31. docs (e.g. poetry) in our authoring systems, and then PUBLISH them as
  32. HTML. Some poetry is published on e.g. audio tape, but the vast
  33. majority is published on paper and obeys the conventions of line
  34. breaks, verse breaks, page breaks etc, even though the author may
  35. COMPOSE it in very different terms that just don't come across when
  36. reading it. My feeling is that HTML should provide low-level PUBLISHING
  37. functions, but not aetherial concepts or <poem> tags.
  38.  
  39. My best suggestion is an argument to <pre> ; e.g. <pre monofont> and
  40. <pre normalfont>. Or maybe <pre style="em">, where the style argument
  41. can be any valid text style tag or "plain"? This allows me to separate
  42. the lines of my address (or poem) properly, introduces no extra tags,
  43. and <pre> with no argument can default to the normal meaning of
  44. "monospaced, to suit a listing or programming example".
  45.  
  46. OK, on to "page breaks". Or since, this kind of terminology seems to
  47. offend people, may I suggest "multibody files"? It occurs to me that a
  48. special "page break" tag is unneccesary. All we need is a well
  49. established method of handling multiple <body></body> pairs in one file.
  50.  
  51. * Browsers can search across a whole set of short bodies
  52. * Browsers don't have to try to whack the whole of an enormous file onto a text 
  53.   widget. XMosaic already has to break large files into "pages", so it seems 
  54.   like a good idea to make the "pages" more logical.
  55. * Most authors and (the tools they use) consider multiple chapters of one 
  56.   document to logically belong in one file.
  57. * Most readers don't read large documents from page one and progress to the end
  58.  
  59. An obvious example is a technical manual or a Usenet FAQ. All I want to
  60. see is the index and/or table of contents, then the chapter or section
  61. which answers my question. I don't want to wait for vast quantities of
  62. gunk to be mapped into a window ESPECIALLY if it contains inlined
  63. images (e.g. the Vatican library document index). Just show me the
  64. section which is relevent. OK, if I then want to browse down the index,
  65. fine, but let it be my choice.
  66.  
  67. It's possible that these things are solved better by Dave Raggett's
  68. html2 DTD, but I can't get to hplose.hpl.hp.com. Care to give us the IP
  69. address while your netbods set up the name, Dave?
  70.  
  71. Peter Lister                                    p.lister@cranfield.ac.uk
  72. Computer Centre,
  73. Cranfield Institute of Technology,        Voice: +44 234 754200 ext 2828
  74. Cranfield, Bedfordshire MK43 0AL UK         Fax: +44 234 750875